In many software applications, particularly in a networked environment, one or more stateless front-end applications connects to a single, state-full, backend. Events, such as requests to access, modify, and remove various objects, are received at the front-end application, and are passed along to the backend. Often, multiple requests seeking access to the same object are received simultaneously, or nearly so. In most such applications, any such conflicting requests are addressed by locking down an object while it is being accessed.
When an object in a state-full backend is locked down, only the application whose request is currently being handled is allowed to access the object. In this way, object integrity is preserved, and corruption is avoided, as potentially conflicting access and modification requests are not performed simultaneously on the object.
A number of problems are inherent to this approach. For example, the object handler lacks a means of determining when a new event is received. The event dispatching mechanism cannot differentiate between an event that is already being processed, and one awaiting processing. And, as with most computer applications, a system failure results in a significant loss of time, as no record is retained of what events have been processed, are currently being processed, and remain to be processed.